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ABSTRACT 


The objective of this project was to develop »pBCifu 
integrated environment for off-line programming graphical 
path verification, and debugging for robot ic t ion 

alternatives were compared. The first uias pnRSIM a 

nF the ASEA Off-line Programming package with RuBbin , 
robotic simulation pro B ram. The second alternative mas the 
ourchale of the commercial product ISRIP. The needs of the 
RADL CRobotics Applications Deveiopment Laboratoryj we 
explored and the alternatives were evaluated based on these 
needs. As a result, IGRIP was proposed as the best solution 

to the problem. 
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SUMMARY 


The RADL at KSC is experiencing competition For on-line time 
with the robots. This is because all of the programming, 
development, and debugging ties up the robots. To alleviate 
this problem, it was proposed that an off-line programming 
and debugging environment be developed. This project 
explored two alternatives: 

11 the integration oF two existing software packages, 
ASEA OFF-1 ine Programming and ROBSIM. 

S! the purchase of commercially available soFtware. 

The commercially available software chosen was Deneb 
Robotic’s IGRIP. This package was evaluated because it 
could run on the InterGraph workstations currently at KSC. 

This report exams the types of projects the RADL is involved 
with and determines several Features which would be 
desirable. Next, each of the alternatives was evaluated 
based on these and other criteria. 

The ASEA OFF-1 ine Programming package was Found to be easy 
to use except For the wrist orientation coordinates. The 
yggi - interface on the ROBSIM package was difficult to use. 
The potential user had to understand joint transformation 
matrices, Euler angles, and dynamic parameters. In 
addition, the current version at K5C had several bugs. 

The IGRIP package was found to be extremely easy to use and 
performed most of the Functions required by the RADL 
personnel. The one capability it did not possess was 
dynamic simulation. However, this could be supplied by 
interfacing one of several commercial packages. The IGRIP 
package was superior in all respects to the other 
alternative except For price. Even in this category, it was 
unclear how much it would cost to integrate ASEA and ROBSIM, 
thus making a cost comparison difficult. 

The final recommendation in this project was to purchase 
IGRIP for the InterGraph workstations that currently exist 
at KSC. 
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I.- INTRODUCTION 


1.1 ROBOTICS AT KENNEDY SPACE CENTER 

With the recent proposal by President Bush to establish a 
permanent lunar base and initiate a manned mission to Mars, 
there will be an increase in activity at KSC . Launches will 
occur more Frequently and more payloads will be processed. 
In order to meet this goal, NASA will need to apply robots 
to tasks in space as well as ground preparation and 
servicing of spacecraft . Robots have replaced men 
performing dangerous or tedious tasks in the industrial and 
service sectors. It is only natural that space related 

tasks should be the next Frontier for robotics. Several 
tasks at KSC are candidates For robot applications; for 
example, working with hazardous fuels and cryogenics, 
inspecting spacecraft and payloads, and performing last- 
second tasks at the launch pads. 

1.2 MISSION OF THE ROBOTICS APPLICATIONS DEUELOPMENT 
LABORATORY 

The Robotics Applications Development Laboratory CRADL5 was 
established to explore the feasibility of applying robotic 
principles to the shuttle/payload ground processing 
activities at KSC. The robotic prototype system in the 
laboratory provides a testbed For projects dealing with many 
aspects of ground preparation. Furthermore, the laboratory 
provides a training environment in robotics for engineers. 
With the expected increase in activity, the laboratory will 
experience increasing competition For resources, especially 
programming time on the robots. 

1.3 OBJECTIUE OF THIS RESEARCH PROJECT 

The objective of this research project was to advise RADL 
personnel of the best way to proceed in order to alleviate 
the problem of limited availability of programming time and 
application time on the robots in the RADL. Furthermore, an 
analysis of current and future projects has shown that 
several types of tasks consistently reoccur . Tools that 
could be applied to these tasks have been evaluated and are 
discussed in greater detail in this paper. A list of these 
tasks includes the capability to: 

program off-line which reduces the time actually 

spent using the robot 
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graphically view the robot moving 
environment to detect many programming 
before the robot is operated 


through its 
errors even 


detect collisions between objects in the environment 


place various robots Cor variations of a proposed 

design!) in a graphical model of the environment to 
determine optimal configurations and limits 


design and locate fixtures in the environment to 
minimize access problems 


detect singularities in a program before it is 
actually run on the robot 


view multiple devices moving within the 
and verify the communication signals 
devices 


environment 
between the 


II. RADL FACILITIES 


2.1 ROBOTS 

In its current configuration, the RADL consists of two 
robots: an ASEA IRB SO/B and a PUMA 560. Host of the 

development work to date has been is 

IT* 

larSe "ork envelope. It is an ideal .candidate to worsen 
larne nieces of equipment that exist at KSC . 
robot is also equipped with an adaptive control option that 
allouis 1 it to dynamically alter its path planning based on 
outside signals. 

E.E PERIPHERAL EQUIPMENT 

The robots in the RADL are interfaced to several other 
that^has^the* ^apability^to^upload/down^oad^programs and 
regie" oonironer that can control process outputs and 
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monitor inputs, and a flasterUiew graphics presentation 
system . 


III. APPLICATION AREAS 


There are several projects at KSC , currently underway or 
proposed, that could be significantly enhanced by the 
findings of this research project. This section will 
briefly describe some of these projects and relatB how off - 
line programming and graphical verification of path planning 
could enhance the projects. 


3.1 ORBITER TILE INSPECTION 


Each time an orbiter returns to earth, the protective heat 
tiles must be inspected for damage and misalignment. Of 
particular importance are the leading and trailing edges of 
the wings, the nose, and around the landing gear. Each of 
the tiles are individually inspected; a time consuming and 
tedious task that is ideally suited for a robot. Past 
projects in the RADL have shown that a robot can effectively 
inspect a mockup of a section of the orbiter. However, 
before a robot is used near a real arbiter, a graphical 
verification of the program would provide a substantially 
increased level of confidence. 


If a decision were made to incorporate a robot in the 
inspection process, NASA would require specifications about 
the type of robot that should be purchased or designed. A 
state-of-the-art design environment could show the robot 
moving through its range of motion next to the orbiter. The 
number and location of positions required to inspect the 
orbiter could be determined without even turning the robot 
on, let alone moving it near the orbitBr . If a robot was 
being designed to perform the task, the designer could 
experiment with various link lengths, Joint limits, and 
joint configurations to determine the optimal configuration. 
Commercially available robots could be quickly and easily 
compared to determine the optimal robot for the inspection 
task . 


3. E INSPECTION AND PROCESSING DF ORBITER PAYLOADS 

This task would employ a robot to inspect the payload of the 
shuttle prior to lift off. It would also involve tasks to 
bring experiments on-line Just prior to lift off. Examples 
would include turning switches on, removing lens caps, 
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verifying that pieces are in place, and inspecting For sharp 
edges that could catch and tear the space suits of the 

astronauts . 

This robot mould most likely be located in the PCR 
Changeout Room! at the launch pad. A graphical 0^ 

determi ne n the°opt i ma 1 "conf igura^on^ Also . ^ — jl 

allow'oFF-l inB^program°generatian^of ^the B path to perform the 

inspection tasks. Collision detection capabilities cou 
verify that no collisions mould occur. 


DRBITER RADIATDR INSPECTION 


3.3 

Prior to each flight, the radiators on the arbiter must be 
OPF . 

This oroiect mould benefit from a graphical design 
inis project. m nF Fhp OPF to determine the 

environment by using a model of t „ Dr - a *.= =FFicientlu 

envelope requirements For the robot to operate efficiently 

Collision detection and program generation mould 

important in the later stages. 


IU. CONSIDERATION OF ALTERNATIUE METHODS 

The current method of robot programming in the RADL utilizes 
a teach pendant. While this is an adequate method For 
rpnpHtive tasks such as in a manufacturing environment, it 

for highly intelligent tasks -here complex 
decisions must be made in a constantly changing envi 

sffi jrssrs-r Jsr»r-!= 

can provide an adequate solution, it seldom a PP r oaches the 
opt ima 1 ; primarily because the designer do ss -t have t me 
to try many different alternatives. A graphical oesig 

environment can provide the designer i mi °° 

make changes in the design and viem the results. 
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4 . 1 


ASEA OFF-LINE PROGRAMMING PACKAGE WITH R0B5IM 


The First alternative explored was to integrate several 
pieces of soFtware currently in the RADL . This was proposed 
to minimize the total cost oF the project. The First piece 
oF soFtware was the ASEA OFF- line Programming Package which 
uses the language ARLA . This soFtware runs on the ^ lcro ^ 
II and communicates with the robot using the ASEA Computer 
Link hardware. It provides the capability to program 
without the teach pendant. Generally, the same Functions 
are provided in ARLA as with the teach pendant LEI . 


Locations in the program can be 
system oF the robot, registers 
using the teach pendant. The 
while trying to program entirely 
scheme oF representation For wri 
diFFicult to visualize the map 
the robot coordinate system tak 
TCP CTool Center Point) deFiniti 


entered using the coordinate 
or a special record mode 
biggest problem encountered 
oFF-line was using the ASEA 
st coordinates. It is very 
between the real world and 
ing into account the current 
on . 


Other limitations Found in ARLA are the lack oF arithmetic 
and trigonometric Functions, the lack oF data processing 
capabilities, and the Failure to incorporate the robot track 
as an additional robot axis. Arithmetic and trigonometric 
Functions are important to calculate positions an 
orientations oF objects in the environment. Data processing 
capabilities are required to store data in Files or access 
databases. Finally, the robot track is considered to be an 
external axis by the controller. When a position is entered 
using the keyboard, the option is not given to enter values 
For the external axes. Therefore, the calculation oF the 
coordinates oF the TCP are not aFFected by the track 
position. This makes it diFFicult to use the track in ay 
mode other programming with the pendant. 

Since the ASEA package does not include any kind oF 
graphics, and hence no way to debug a program except to test 
it on the robot, the ROBSIM package was evaluated as the 
graphical display tool. ROBSIM was developed by Martin 
Marietta For LaRC C3,43. It was designed to be a dynamic 
simulator taking into account the physical properties and 
constants of the links and joints. ROBSIM can provide a 
graphical simulation of a robot in its environment iF the 
appropriate hardware is available CEvans and Sutherland 
terminal). Otherwise, it must be run without graphics. 
There were several problems encountered in trying o mo 
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will describe 


robots with ROBS I M . The following sections 
some of these problems in more detail. 

4 1.1 GRAPHICS TERMINAL REQUIREMENTS. ROBSIM requires an 
Evans and Sutherland terminal for proper graphics display^ 
This type of terminal has a series of analog dials that can 
be used to change the perspective of the display. Without 
the capability to alter the perspective from the default 
side view the user cannot determine where the robot is 
three-d imens i ona 1 space . Although the help «£* 

a UTBHO terminal can be used, it only P .. 

dimensional side view. No capability exists to alter 
perspective in software. 

4 i P INTEGRATION WITH INTERGRAPH. It would be difficult 
a^d time consuming to rewrite the ROBSIM I/O routines to 
interface with th5 InterGraph family of ^stations which 
are available throughout KSC . The hooks are not really 
available, and more importantly are not documented m the 
current version of ROBSIM. 

4 l 3 LACK OF UPDATED DOCUMENTATION. The documentation is 
different from the current version of ROBSIM that is running 
on the WAX. The documsntatipn is for the version developed 
hu Sartin Marietta. The version of ROBSIM currently running 
on The UA? uas modified by LaRC to reside in their 

environment . 

4 1 4 INUERSE KINEMATIC DIFFERENCES. ROBSIM uses its own 
internal kinematic solutions to relate "slues to the 

TCP position. The user must be knowledgeable about joint 
and transformation matrices and Euler angles to 

understand hou to use the program. The «°BSIM solutions and 
displays would only be as good as the "° del w^h Y 10 u00 ^ 

entered for the robot. However, since ROBSIM does not 
provide for collision detection, the lack of accuracy would 
not cause a significant problem. 

4 1.5 DATA EXCHANGE FORMAT. The two packages in question 
do not store data in the same format. Conversion j Programs 
could be written to interface the two packages, bu 
expense of user-friendliness and speed. 

4.1.6 PACKAGES LOCATED ON DIFFERENT SYSTEMS. Currently the 
ASEA Off-Line Programming package is installed ^h 

5 TI in the RADL and the ROBSIM package is installed 
onTe Engineering UAX Since the ASEA program must remain 
connected to the Computer Link, ROBSIM would ideally 
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ported to the same system. Unfortunately, the MicroUax II 
does do have enough disk space to store the ROBS I M . The two 
packages could be interfaced using DECNET , by sacrificing 
some speed and convenience. 

4.2 i GRIP OFF-LINE ROBOT PROGRAMMING AND SIMULATION SYSTEM 

IGRIP is a commercially available software package that 
combines many of the features required in the RADL . The 
software was written by Deneb Robotics, Inc. and has been on 
the market for several years. It is considered by many to 
be one of the best in its class. Since InterGraph has taken 
the IGRIP software and ported it to their hardware and since 
there are many InterGraph workstations already located at 
K5C , a cost effective solution exists: the purchase and 
installation of IGRIP on an existing system. 

4.2.1 FEATURES OF IGRIP. Although a complete description 
of IGRIP is beyond the scope of this report, some of the 
highlights are mentioned in this section so that the various 
options can be compared. IGRIP integrates a CAD system with 
a simulation /animat ion system to provide high quality, 
shaded surface images of the environment. Multiple robots 
with unlimited degrees of freedom can move through the 
environment, manipulate objects, and communicate with other 
devices. Collision detection and near miss situations can 
be detected between any group of objects in the environment. 
The simulation can be recorded and played back at a later 
time . 

The inverse kinematic solutions can be generated by generic 
algorithms or user written in the language C. Complex 
devices can be constructed which have joint limit 
dependencies. The path the robot is to traverse is defined 
using tag points. Unreachable points on the path can be 
easily detected. A special mode automatically places a 
robot so that a group of points can be accessed. This mode 
would be especially useful in the tile inspection task. 

Using GSL, the user can construct descriptions of how a 
device will operate and communicate with other devices in 
the environment. Over 40 commercially available robots are 
predefined in IGRIP. The capability also exists, via 
supplied translators, to upload/download native robot code 
for B major robot manufacturers (including the ASEA and PUMA 
robots located in the RADL) . 


316 


be purchased . 

"i ; “r”:;"HK""bS‘' -, ~s;. 3£& 


4.3 OTHER ALTERNATIVES 


T u prp arB other soFtware packages on the market which have 
Features similar to 1BRIP. Houever none have been por^ 
to use InterGraph hardware and CAD tiles. addit ional 

detail . 


U. COMPARISON OF ALTERNATIVES 

This section .ill attempt to compare the tuo al ^natives 
using criteria uhich are important to the RADL . ft summa y 
of the results of this section are listed in Table 1. 

5.1 USER-FRIENDLINES5 

This is probably the most important criterion ^comparing 
uiefSlness of the packages. If a system is difficult to 
use, no one .ill take th^tim^to Ijj-it ~ - 

this citenory rnB It is a mature product that has a proven 

sss 1 ^^"^ 1 p?o^es a ma:r= 

is acceptable, the ROBSin package is and 

use The documentation does not agree witn 

several bugs exist which Frustrate the user. 
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Table 1 . Comparison of Alternatives 
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5 . 2 COST 

The ASEA/ROBSIM package is the least expensive alternative 
because both package* are already at KSC . Ho.everthere 
would be a cost associated with interfacing the two P a ^Sss 
and defining a model of the ASEA robot in the ROBSIM 
oackaqe For optimal use of graphics, an Evans and 

Sutherland terminal would be required at an additional cost. 
Furthermore, the current version of ROBSIM has sev ®ral ug 
which would need to be removed. A rough estii SuStem 
time/cost required to define the model and build the syste 
S to 3 man-months. The I OR IP package, on the other 
hani has a higher initial pest <*60,0001, but this includes 
the cost to install the software and train the operators. 


5.3 TRAINING 

I GRIP has superior training because of the 

vendor-supplied courses. According to the InterGraph 

representative, the cost of the software includes training 
for 5 people. To further reduce the training cost. *t mig 
be Dossible to negotiate for this training to take place at 
KSC rather than ?heDeneb school. ASEA/ROBSIM training 
would be totally self-directed. Other than the resident 
expert who performs the integration of the two packages no 
one would be available to answer questions pertaining to the 
working environment. 

5.4 COMPATIBILITY WITH OTHER NASA CENTERS 

This is a difficult category to award because there are no 
official packages at other NASA centers. 1 B - 

doubtful that anyone will use the 1 perform 

ASEA/ROBSIM, some centers may be using ROB package 

dynamic modeling. MSFC is currently using the IGRIP package 
anHighTy recommends it. Choosing this option uould ensure 
compatibility between KSC and MSFC. 

5.5 FLEXIBILITY 

Flexibility is defined here as the ease to add new robots 
and/or alter existing models. In this category, IGRIP is 
far superior to ASEA/ROBSIM. IGRIP has over 40 commercial 
robots predefined, including the PUMA located in the RADL. 
This feature provides the user with a unique capability. 
Giien that the application environment is already defined 
teuser can insert several different types of robots to 
determine uhich one is best-suited For the task. An 
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estimate of the cycle time can also be determined. Eight of 
the most common off-line programming language translators 
are also included to allow the user to generate downloadable 
programs for the robot. Both the ASEA CARLA) and PUMA (UAL 
II) translators are included. 

With the A5EA/R0BSII1 packages, each new robot would have to 
be kinematically modelled. Also a separate off-line 
programming package would have to be purchased and 
integrated with ROBS IM . This would be a labor intensive 
operation repeated each time a robot is purchased. 


5.6 SUPPORT /UPDATES 


I GRIP has the best support of the two alternatives. Support 
is available from InterGraph and Deneb Robotics. Updates 
are free for some specified time period C 1 to E years). 


On the other hand, the ASEA/ROBSIM combination offers little 
support. While ASEA will continue to support the ARLA 
language, ROBSIM is not currently supported and the 
likelihood of updates being released is low. Each time an 
update is received, the two packages must be combined again 
and the interface code rewritten. 

5.7 COLLISION DETECTION 


Since no collision detection is available in ROBSIM, IGRIP 
is superior in this category. IGRIP provides collision 
detection using an exact, surface to surface intersection 
calculation. Checking can be limited to any number of 
objects. A near miss mode and nearest distance between two 
objects mode are also available with the tradeoff of a 
reduction in processing speed. 


5.0 TYPE OF GRAPHICS 


IGRIP is also superior in this category, 
depicted using wireframe, shaded surface, 
modes. Calculations and screen updates 
quickly, depending on the number of e 
environment . 


Images can be 
or transparent 
are performed 
lements in the 


ROBSIM provides only wireframe images. These images are 
adequate when using the suggested Evans and Sutherland 
terminal (which is not available at KSC) . With a UTB40 
terminal, only two-dimensional images are available. 
Furthermore, the point of reference cannot be changed. 
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Without the Evans and Sutherland terminal, the graphical 
analysis capabilities are severally limited. 


5.5 KINEMATIC SOLUTIONS 


IGRIP is the best choice in this category. The inverse 
kinematic solutions are implemented For all of the 
commercial robots included in the package. Furthermore the 
user can write programs to calculate the kinematic solutions 
For any type oF device. Thus, dynamic eFFects can be 
incorporated in the calculations. 


The user has no control over the kinematic 
the ROBSIM package. The program would have 
add this Feature, iF it was required. 


solutions used in 
to be altered to 


5.10 AUAILABILITY 


IGRIP is available immediately 
would require several man-months 
completed . 


The ASEA/ROBSIM package 
For a useable version to be 


UI . RE5ULTS AND DISCUSSION 

In comparing the two alternatives discussed in the previous 
section, it becomes obvious that in every aspect other than 
initial cost IGRIP is better suited than the ASEA/ROBSIM 
combinat io° S f or the needs of the Jh. «rrjr-n»ij 

cost is extremely small when compared to the additional 
capabilities that can be perFormed by IGRIP users. 

IGRIP oFFers an additional capability not ment io ™ d ® 
requirement by the RADL personnel: being ab b to create 
application scenarios quickly and easily to sell projects to 
upper levels oF management and other Funding bodies. It is 
t?SS that a picture is worth a thousand words IF you can 
show the potential funding agency a video of a proposed 
robot gripper, or Fixture in operation, they will have more 
conFidence and will be more likely to supply the Funding. 
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CONCLUDING REMARKS 


In this project two alternatives were compared to Find the 
one which was best-suited For use in the RADL at KSC . It 
was desired that an integrated environment For oFF-line 
programming, debugging, and graphical veriFication oF path 
planning be developed . 

The First alternative, combining the A5EA OFF-line 
Programming package with ROBSIM, had several disadvantages. 
It was awkward to learn and use, it did not provide 
collision detection, and it did not provide many oF the 
extra Features Found in the second alternative. ROBSIM, in 
its current Form, would not run on the Engineering UAX . 
Extensive modiFicat ions would bB required to intBrFace it 
with the ASEA package. 

IGRIP, on the other, was Found to be user-Friendly. It 
perFormed all oF the required Functions except dynamic 
simulation. This Feature could be achieved by purchasing 
additional software to analyze the dynamics. IGRIP provided 
better graphics, a modelling environment, and over 40 
commercial robots already deFined. In addition, translators 
mere available For both the robots in the RADL. 

With the additional Features provided by IGRIP, it was 
easier to justiFy the additional cost. Since, workstations 
are available, the only additional cost would be that oF the 
soFtware. ThereFore, in conclusion, it is recommended that 
the RADL purchase IGRIP For use as an integrated 
environment . 
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